<html>
<head><meta charset="utf-8"><title>Opting out of default-implemented trait · t-lang · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/index.html">t-lang</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html">Opting out of default-implemented trait</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="246041079"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246041079" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246041079">(Jul 15 2021 at 01:10)</a>:</h4>
<p>When working on <code>https://github.com/rust-lang/rust/pull/87146</code>, I ran into a bug caused by an <code>ast::Visitor</code> forgetting to override a particular method. All of the visitor methods have a default implementation, but for some impls of that traits, it would be useful to require an explicit override. This would force us to check if the default impementation is correct for that particular impl</p>



<a name="246041124"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246041124" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246041124">(Jul 15 2021 at 01:10)</a>:</h4>
<p>I think this could potentially be useful for other crates as well - though this would be an explicit Semver opt-out if used for a foreign trait impl, it could be helpful for crates that want to ensure that they're handling all cases for a visitor-like trait</p>



<a name="246041187"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246041187" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246041187">(Jul 15 2021 at 01:12)</a>:</h4>
<p>If we got some kind of opt-out for <code>#[non_exhaustive]</code> (e.g. <code>#[exhaustive]</code> match foo { .. }<code>) that allows you to omit the </code>_ =&gt; {}` branch, then we could potentially re-use it for this feature</p>



<a name="246041195"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246041195" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Aaron Hill <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246041195">(Jul 15 2021 at 01:12)</a>:</h4>
<p>e.g. <code>#[exhaustive] impl MyTrait for MyType { ... }</code> would error if there are any default-implemented methods being used</p>



<a name="246041274"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246041274" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Taylor Yu [they/she] <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246041274">(Jul 15 2021 at 01:14)</a>:</h4>
<p>you'd have to remember to add that attribute on the implementation to begin with, right? but i guess if there are lots of default methods, it would help to detect one that's not overridden</p>



<a name="246630475"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246630475" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246630475">(Jul 20 2021 at 18:28)</a>:</h4>
<p><span class="user-mention silent" data-user-id="125294">Aaron Hill</span> <a href="#narrow/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait/near/246041187">said</a>:</p>
<blockquote>
<p>If we got some kind of opt-out for <code>#[non_exhaustive]</code> (e.g. <code>#[exhaustive]</code> match foo { .. }<code>) that allows you to omit the </code>_ =&gt; {}` branch, then we could potentially re-use it for this feature</p>
</blockquote>
<p>I don't think it can allow <em>omitting</em> the <code>_ =&gt;</code> branch -- since that breaks the core point of being <code>non_exhaustive</code> -- but there could be an opt-in to get a lint about missing something.  (And with cap-lints, that would end up still actually compiling as a dependency when the type got an extra variant.)</p>



<a name="246696936"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246696936" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246696936">(Jul 21 2021 at 09:30)</a>:</h4>
<p>We allow omitting the <code>_</code> <em>in the same crate</em>, for non-exhaustive, right?</p>



<a name="246696964"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246696964" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246696964">(Jul 21 2021 at 09:30)</a>:</h4>
<p>That probably wouldn't in this case, admittedly</p>



<a name="246696988"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246696988" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> nikomatsakis <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246696988">(Jul 21 2021 at 09:30)</a>:</h4>
<p>I agree with the concept</p>



<a name="246702850"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246702850" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246702850">(Jul 21 2021 at 10:43)</a>:</h4>
<p><span class="user-mention silent" data-user-id="125270">scottmcm</span> <a href="#narrow/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait/near/246630475">said</a>:</p>
<blockquote>
<p><span class="user-mention silent" data-user-id="125294">Aaron Hill</span> <a href="#narrow/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait/near/246041187">said</a>:</p>
<blockquote>
<p>If we got some kind of opt-out for <code>#[non_exhaustive]</code> (e.g. <code>#[exhaustive]</code> match foo { .. }<code>) that allows you to omit the </code>_ =&gt; {}` branch, then we could potentially re-use it for this feature</p>
</blockquote>
<p>I don't think it can allow <em>omitting</em> the <code>_ =&gt;</code> branch -- since that breaks the core point of being <code>non_exhaustive</code> -- but there could be an opt-in to get a lint about missing something.  (And with cap-lints, that would end up still actually compiling as a dependency when the type got an extra variant.)</p>
</blockquote>
<p>I would like to see such, but I would strongly want that to be deny-by-default/forbid-by-default (which is probably reasonable if it's opt-in per-match). I deal with parsing targets in a library that is basically 5 <code>#[non_exhaustive]</code> enums and a struct (and a ton of pain). The component types are non_exhaustive so I can add components in minor versions (at the same time, I also reserve the right to change the parsing rules/how certain strings parse), so the library doesn't end up with major version &gt;100. However, downstream, I have a few things that are determining additional properties of the targets, and the <code>_ =&gt; {}</code> pattern is just a runtime error (of some kind) waiting to happen.</p>
<p><span class="user-mention silent" data-user-id="116009">nikomatsakis</span> <a href="#narrow/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait/near/246696936">said</a>:</p>
<blockquote>
<p>We allow omitting the <code>_</code> <em>in the same crate</em>, for non-exhaustive, right?</p>
</blockquote>
<p>That is indeed allowed. I've used that exact thing for the same thing as above (but for internal property checking/canonicalization, rather than external).</p>



<a name="246743621"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246743621" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246743621">(Jul 21 2021 at 16:28)</a>:</h4>
<p><span class="user-mention" data-user-id="125270">@scottmcm</span> I think they were hinting at proposals / suggestions out there <strong>targeting tests only</strong> for libraries wanting to be <em>as exhaustive as possible</em> to make sure they are up-to-date with their dependency's variants at the time of running CI / maintaining their own stuff. Outside testing, they'd still have to handle the <code>_ =&gt;</code> branch to preserve Semver, of course!</p>



<a name="246750375"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/213817-t-lang/topic/Opting%20out%20of%20default-implemented%20trait/near/246750375" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/213817-t-lang/topic/Opting.20out.20of.20default-implemented.20trait.html#246750375">(Jul 21 2021 at 17:17)</a>:</h4>
<p>I don't think a different rule for "this is tests" is a good idea.  I think the lint that's deny but still requires the <code>_ =&gt;</code> is fine -- the people building the tests will get it.  It doesn't need to be a hard error.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>